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Abstract 


The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network 
operator or an application to specify a packet processing program by encoding a sequence of 
instructions in the IPv6 packet header. 


Each instruction is implemented on one or several nodes in the network and identified by an 
SRv6 Segment Identifier in the packet. 


This document defines the SRv6 Network Programming concept and specifies the base set of 
SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. 
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This document is a product of the Internet Engineering Task Force (IETF). It represents the 
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1. Introduction 


Segment Routing [RFC8402] leverages the source routing paradigm. An ingress node steers a 
packet through an ordered list of instructions, called "segments". Each one of these instructions 
represents a function to be called at a specific location in the network. A function is locally 
defined on the node where it is executed and may range from simply moving forward in the 
segment list to any complex user-defined behavior. Network Programming combines Segment 
Routing functions, both simple and complex, to achieve a networking objective that goes beyond 
mere packet routing. 


This document defines the SRv6 Network Programming concept and specifies the main Segment 
Routing behaviors to enable the creation of interoperable overlays with underlay optimization. 


[SRV6-NET-PGM-ILLUST] illustrates the concepts defined in this document. 


Familiarity with the Segment Routing Header [RFC8754] is expected. 


2. Terminology 


The following terms used within this document are defined in [RFC8402]: Segment Routing (SR), 
SR Domain, Segment ID (SID), SRv6, SRv6 SID, SR Policy, Prefix-SID, and Adj-SID. 


The following terms used within this document are defined in [RFC8754]: Segment Routing 
Header (SRH), SR source node, transit node, SR Segment Endpoint Node, Reduced SRH, Segments 
Left, and Last Entry. 


The following terms are used in this document as defined below: 


FIB: Forwarding Information Base. A FIB lookup is a lookup in the forwarding table. 
SA: Source Address 

DA: Destination Address 

L3: Layer 3 

L2: Layer 2 

MAC: Media Access Control 

EVPN: Ethernet VPN 

ESI: Ethernet Segment Identifier 


Per-CE VPN label: A single label for each attachment circuit that is shared by all routes with the 
same "outgoing attachment circuit" (Section 4.3.2 of [RFC4364]) 
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Per-VRF VPN label: A single label for the entire VPN Routing and Forwarding (VRF) table that is 
shared by all routes from that VRF (Section 4.3.2 of [RFC4364]) 


SL: The Segments Left field of the SRH 


SRv6 SID function: The function part of the SID is an opaque identification of a local behavior 
bound to the SID. It is formally defined in Section 3.1 of this document. 


SRv6 Endpoint behavior: A packet processing behavior executed at an SRv6 Segment Endpoint 
Node. Section 4 of this document defines SRv6 Endpoint behaviors related to traffic- 
engineering and overlay use cases. Other behaviors (e.g., service programming) are outside 
the scope of this document. 


An SR Policy is resolved to a SID list. A SID list is represented as <S1, S2, S3> where S1 is the first 
SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit along the SR path. 


(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 


e Source Address (SA), Destination Address (DA), and next header (SRH). 
e SRH with SID list <S1, S2, S3> with Segments Left = SL. 


Note the difference between the <> and () symbols: <S1, S2, S3> represents a SID list where S1 
is the first SID and S3 is the last SID to traverse. (S3, S2, S1; SL) represents the same SID list 
but encoded in the SRH format where the rightmost SID in the SRH is the first SID and the 
leftmost SID in the SRH is the last SID. When referring to an SR Policy in a high-level use 
case, it is simpler to use the <S1, S2, S3> notation. When referring to an illustration of the 
detailed packet behavior, the (S3, S2, S1; SL) notation is more convenient. 


e The payload of the packet is omitted. 


2.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. SRv6 SID 


[RFC8402] defines an SRv6 Segment Identifier as an IPv6 address explicitly associated with the 
segment. 


When an SRV6 SID is in the Destination Address field of an IPv6 header of a packet, it is routed 
through transit nodes in an IPv6 network as an IPv6 address. 


Its processing is defined in Section 4.3 of [RFC8754] and reproduced here as a reminder: 
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Without constraining the details of an implementation, the SR segment endpoint node 
creates Forwarding Information Base (FIB) entries for its local SIDs. 


When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match 
lookup on the packet's destination address. This lookup can return any of the following: 


e A FIB entry that represents a locally instantiated SRv6 SID 

e A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID 
° A FIB entry that represents a nonlocal route 

e No Match 


Section 4 of this document defines a new set of SRv6 SID behaviors in addition to that defined in 
Section 4.3.1 of [RFC8754]. 


3.1. SID Format 


This document defines an SRV6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is 
encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits 
of arguments (ARG). L, the locator length, is flexible, and an operator is free to use the locator 
length of their choice. F and A may be any value as long as L+F+A <= 128. When L+F+A is less 
than 128, then the remaining bits of the SID MUST be zero. 


A locator may be represented as B:N where B is the SRV6 SID block (IPv6 prefix allocated for SRv6 
SIDs by the operator) and N is the identifier of the parent node instantiating the SID. 


When the LOC part of the SRv6 SIDs is routable, it leads to the node, which instantiates the SID. 
The FUNCT is an opaque identification of a local behavior bound to the SID. 


The term "function" refers to the bit string in the SRv6 SID. The term "behavior" identifies the 
behavior bound to the SID. Some behaviors are defined in Section 4 of this document. 


An SRv6 Endpoint behavior may require additional information for its processing (e.g., related to 
the flow or service). This information may be encoded in the ARG bits of the SID. 


In such a case, the semantics and format of the ARG bits are defined as part of the SRv6 Endpoint 
behavior specification. 


The ARG value of a routed SID SHOULD remain constant among packets in a given flow. Varying 
ARG values among packets in a flow may result in different ECMP hashing and cause reordering. 
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3.2. SID Allocation within an SR Domain 


Locators are assigned consistent with IPv6 infrastructure allocation. For example, a network 
operator may: 


e Assign block B::/48 to the SR domain 
e Assign a unique B:N::/64 block to each SRv6-enabled node in the domain 


As an example, one mobile service provider has commercially deployed SRv6 across more than 
1000 commercial routers and 1800 whitebox routers. All these devices are enabled for SRv6 and 
advertise SRv6 SIDs. The provider historically deployed IPv6 and assigned infrastructure 
addresses from the Unique Local Address (ULA) space [RFC4193]. They specifically allocated 
three /48 prefixes (Country X, Country Y, Country Z) to support their SRv6 infrastructure. From 
those /48 prefixes, each router was assigned a /64 prefix from which all SIDs of that router are 
allocated. 


In another example, a large mobile and fixed-line service provider has commercially deployed 
SRV6 in their country-wide network. This provider is assigned a /20 prefix by a Regional Internet 
Registry (RIR). They sub-allocated a few /48 prefixes to their infrastructure to deploy SRv6. Each 
router is assigned a /64 prefix from which all SIDs of that router are allocated. 


IPv6 address consumption in both these examples is minimal, representing less than one 
billionth and one millionth of the available address space, respectively. 


A service provider receiving the current minimum allocation of a /32 prefix from an RIR may 
assign a /48 prefix to their infrastructure deploying SRv6 and subsequently allocate /64 prefixes 
for SIDs at each SRV6 node. The /48 assignment is one sixty-five thousandth (1/216) of the usable 
IPv6 address space available for assignment by the provider. 


When an operator instantiates a SID at a node, they specify a SID value B:N:FUNCT and the 
behavior bound to the SID using one of the SRv6 Endpoint Behavior codepoints of the registry 
defined in this document (see Table 6). 


The node advertises the SID, B:N:FUNCT, in the control plane (see Section 8) together with the 
SRv6 Endpoint Behavior codepoint identifying the behavior of the SID. 


An SR source node cannot infer the behavior by examination of the FUNCT value of a SID. 


Therefore, the SRv6 Endpoint Behavior codepoint is advertised along with the SID in the control 
plane. 


An SR source node uses the SRv6 Endpoint Behavior codepoint to map the received SID 
(B:N:FUNCT) to a behavior. 


An SR source node selects a desired behavior at an advertising node by selecting the SID 
(B:N:FUNCT) advertised with the desired behavior. 
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As an example: 


e A network operator may assign an SRv6 SID block 2001:db8:bbbb::/48 from their in-house 
operation block for their SRv6 infrastructure. 

e A network operator may assign an SRv6 Locator 2001:db8:bbbb:3::/64 to one particular 
router, for example Router 3, in their SR Domain. 

e At Router 3, within the locator 2001:db8:bbbb:3::/64, the network operator or the router 
performs dynamic assignment for: 


o Function 0x0100 associated with the behavior End.X (Endpoint with L3 cross-connect) 
between router 3 and its connected neighbor router (e.g., Router 4). This function is 
encoded as a 16-bit value and has no arguments (F=16, A=0). 


This SID is advertised in the control plane as 2001:db8:bbbb:3:100:: with an SRv6 Endpoint 
Behavior codepoint value of 5. 


o Function 0x0101 associated with the behavior End.X (Endpoint with L3 cross-connect) 
between router 3 and its connected neighbor router (e.g., Router 2). This function is 
encoded as a 16-bit value and has no arguments (F=16, A=0). 


This SID is advertised in the control plane as 2001:db8:bbbb:3:101:: with an SRv6 Endpoint 
Behavior codepoint value of 5. 


These examples do not preclude any other IPv6 addressing allocation scheme. 


3.3. SID Reachability 


Most often, the node N would advertise IPv6 prefix(es) matching the LOC parts covering its SIDs 
or shorter-mask prefix. The distribution of these advertisements and calculation of their 
reachability are specific to the routing protocol and are outside of the scope of this document. 


An SRV6 SID is said to be routed if its SID belongs to an IPv6 prefix advertised via a routing 
protocol. An SRv6 SID that does not fulfill this condition is non-routed. 


Let's provide a classic illustration: 
Node N is configured explicitly with two SIDs: 2001:db8:b:1:100:: and 2001:db8:b:2:101::. 


The network learns about a path to 2001:db8:b:1::/64 via the IGP; hence, a packet destined to 
2001:db8:b:1:100:: would be routed up to N. The network does not learn about a path to 
2001:db8:b:2::/64 via the IGP; hence, a packet destined to 2001:db8:b:2:101:: would not be routed 
up to N. 


A packet could be steered through a non-routed SID 2001:db8:b:2:101:: by using a SID list 
<...,2001:db8:b:1:100::,2001:db8:b:2:101::,...> where the non-routed SID is preceded by a routed 
SID to the same node. A packet could also be steered to a node instantiating a non-routed SID by 
preceding it in the SID list with an Adj-SID to that node. Routed and non-routed SRv6 SIDs are the 
SRV6 instantiation of global and local segments, respectively [RFC8402]. 
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4. SR Endpoint Behaviors 


The following is a set of well-known behaviors that can be associated with a SID. 


End 


End.X 


End.T 


End.DX6 


End.DX4 


End.DT6 


End.DT4 


End.DT46 


End.DX2 


End.DX2V 


End.DT2U 


End.DT2M 


End.B6.Encaps 


End.B6.Encaps.Red 
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Endpoint 
The SRv6 instantiation of a Prefix-SID [RFC8402] 


Endpoint with L3 cross-connect 
The SRv6 instantiation of an Adj-SID [RFC8402] 


Endpoint with specific IPv6 table lookup 


Endpoint with decapsulation and IPv6 cross-connect 
e.g., [IPv6-L3VPN (equivalent to per-CE VPN label) 


Endpoint with decapsulation and IPv4 cross-connect 
e.g., IPV4-L3VPN (equivalent to per-CE VPN label) 


Endpoint with decapsulation and specific IPv6 table lookup 
e.g., [IPv6-L3VPN (equivalent to per-VRF VPN label) 


Endpoint with decapsulation and specific IPv4 table lookup 
e.g., IPV4-L3VPN (equivalent to per-VRF VPN label) 


Endpoint with decapsulation and specific IP table lookup 
e.g., IP-L3VPN (equivalent to per-VRF VPN label) 


Endpoint with decapsulation and L2 cross-connect 
e.g., L2VPN use case 


Endpoint with decapsulation and VLAN L2 table lookup 
e.g., EVPN Flexible Cross-connect use case 


Endpoint with decapsulation and unicast MAC L2 table lookup 
e.g., EVPN Bridging Unicast use case 


Endpoint with decapsulation and L2 table flooding 
e.g., EVPN Bridging Broadcast, Unknown Unicast, and Multicast (BUM) 
use case with Ethernet Segment Identifier (ESD filtering 


Endpoint bound to an SRv6 Policy with encapsulation 
SRv6 instantiation of a Binding SID 


End.B6.Encaps with reduced SRH 
SRv6 instantiation of a Binding SID 


Standards Track Page 9 


RFC 8986 SRv6 Network Programming February 2021 


End.BM Endpoint bound to an SR-MPLS Policy 
SRv6 instantiation of an SR-MPLS Binding SID 


Table 1: Endpoint Behaviors 


The list is not exhaustive. In practice, any behavior can be attached to a local SID; for example, a 
node N can bind a SID to a local Virtual Machine (VM) or container that can apply any complex 
processing on the packet, provided there is an SRv6 Endpoint Behavior codepoint allocated for 
the processing. 


When an SRv6-capable node (N) receives an IPv6 packet whose destination address matches a 
FIB entry that represents a locally instantiated SRv6 SID (S), the IPv6 header chain is processed as 
defined in Section 4 of [RFC8200]. For SRv6 SIDs associated with an Endpoint behavior defined in 
this document, the SRH and Upper-Layer header are processed as defined in the following 
subsections. 


The pseudocode describing these behaviors details local processing at a node. An 
implementation of the pseudocode is compliant as long as the externally observable wire 
protocol is as described by the pseudocode. 


Section 4.16 defines flavors of some of these behaviors. 


Section 10.2 of this document defines the IANA registry used to maintain all these behaviors as 
well as future ones defined in other documents. 


4.1. End: Endpoint 


The Endpoint behavior ("End" for short) is the most basic behavior. It is the instantiation of a 
Prefix-SID [RFC8402]. 


Filsfils, et al. Standards Track Page 10 


RFC 8986 SRv6 Network Programming February 2021 


When N receives a packet whose IPv6 DA is S and S is a local End SID, N does the following: 


S01. When an SRH is processed { 

902. If (Segments Left == 9) { 

s03. Stop processing the SRH, and proceed to process the next 
header in the packet, whose type is identified by 
the Next Header field in the routing header. 


S04. } 

S@5. If (IPv6 Hop Limit <= 1) { 

S06. Send an ICMP Time Exceeded message to the Source Address 
with Code @ (Hop limit exceeded in transit), 
interrupt packet processing, and discard the packet. 

S07. 


} 
Ses. max_LE = (Hdr Ext Len / 2) - 1 
Seg. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 
S10. Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 


Sail } 

S12: Decrement IPv6 Hop Limit by 1 

SEE Decrement Segments Left by 1 

$14. Update IPv6 DA with Segment List[Segments Left] 

Sas: Submit the packet to the egress IPv6 FIB lookup for 
transmission to the new destination 

S16. } 


Note: 


The End behavior operates on the same FIB table (i.e., identified by VRF or L3 relay 
ID) associated to the packet. Hence, the FIB lookup on line S15 is done in the same 
FIB table as the ingress interface. 


4.1.1. Upper-Layer Header 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End SID, N does the following: 


S01. If (Upper-Layer header type is allowed by local configuration) { 
S027 Proceed to process the Upper-Layer header 
s03. } Else { 
S04. Send an ICMP Parameter Problem to the Source Address 
with Code 4 (SR Upper-layer Header Error) 
and Pointer set to the offset of the Upper-Layer header, 
interrupt packet processing, and discard the packet. 
s05 } 


Allowing the processing of specific Upper-Layer header types is useful for Operations, 
Administration, and Maintenance (OAM). As an example, an operator might permit pinging of 
SIDs. To do this, they may enable local configuration to allow Upper-Layer header type 58 
(ICMPv6). 
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It is RECOMMENDED that an implementation of local configuration only allows Upper-Layer 
header processing of types that do not result in the packet being forwarded (e.g., ICMPv6). 


4.2. End.X: L3 Cross-Connect 
The "Endpoint with L3 cross-connect" behavior ("End.X" for short) is a variant of the End 


behavior. 


It is the SRv6 instantiation of an Adj-SID [RFC8402], and its main use is for traffic-engineering 
policies. 


Any SID instance of this behavior is associated with a set, J, of one or more L3 adjacencies. 


When N receives a packet destined to S and S is a local End.X SID, the line S15 from the End 
processing is replaced by the following: 


Sis. Submit the packet to the IPv6 module for transmission 
to the new destination via a member of J 


Note: 


S15. If the set J contains several L3 adjacencies, then one element of the set is 
selected based on a hash of the packet's header (see Section 7). 


If a node N has 30 outgoing interfaces to 30 neighbors, usually the operator would explicitly 
instantiate 30 End.X SIDs at N: one per L3 adjacency to a neighbor. Potentially, more End.X could 
be explicitly defined (groups of L3 adjacencies to the same neighbor or to different neighbors). 


Note that if N has an outgoing interface bundle I to a neighbor Q made of 10 member links, N 
might allocate up to 11 End.X local SIDs: one for the bundle itself and then up to one for each L2 
member link. The flows steered using the End.X SID corresponding to the bundle itself get load- 
balanced across the member links via hashing while the flows steered using the End.X SID 
corresponding to a member link get steered over that specific member link alone. 


When the End.X behavior is associated with a BGP Next-Hop, it is the SRv6 instantiation of the 
BGP peering segments [RFC8402]. 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.X SID, process the packet as per Section 4.1.1. 


4.3. End.T: Specific IPv6 Table Lookup 


The "Endpoint with specific IPv6 table lookup" behavior ("End.T" for short) is a variant of the End 
behavior. 


The EndT behavior is used for multi-table operation in the core. For this reason, an instance of 
the End. T behavior is associated with an IPv6 FIB table T. 
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When N receives a packet destined to S and S is a local End.T SID, the line $15 from the End 
processing is replaced by the following: 


S151. Set the packet's associated FIB table to T 
S15.2. Submit the packet to the egress IPv6 FIB lookup for 
transmission to the new destination 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.T SID, process the packet as per Section 4.1.1. 


4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 


The "Endpoint with decapsulation and IPv6 cross-connect" behavior ("End.DX6" for short) is a 
variant of the End.X behavior. 


One of the applications of the End.DX6 behavior is the L3VPNv6 use case where a FIB lookup in a 
specific tenant table at the egress Provider Edge (PE) is not required. This is equivalent to the per- 
CE VPN label in MPLS [RFC4364]. 


The End.DX6 SID MUST be the last segment in an SR Policy, and it is associated with one or more 
L3 IPv6 adjacencies J. 


When N receives a packet destined to S and S is a local End.DX6 SID, N does the following: 


S01. When an SRH is processed { 

$02. If (Segments Left != 0) { 

S03: Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 


S04. } 
S05. Proceed to process the next header in the packet 
S06. 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.DX6 SID, N does the following: 


S01. If (Upper-Layer header type == 41(IPv6) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s03. Forward the exposed IPv6 packet to the L3 adjacency J 
S04. } Else { 
S05: Process as per Section 4.1.1 
S06. } 
Note: 


S01. "41" refers to "IPv6 encapsulation" as defined in the IANA "Assigned Internet 
Protocol Numbers" registry. 
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S03. If the End.DX6 SID is bound to an array of L3 adjacencies, then one entry of the 
array is selected based on the hash of the packet's header (see Section 7). 


4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 


The "Endpoint with decapsulation and IPv4 cross-connect" behavior ("End.DX4" for short) is a 
variant of the End.X behavior. 


One of the applications of the End.DX4 behavior is the L3VPNV4 use case where a FIB lookup ina 
specific tenant table at the egress PE is not required. This is equivalent to the per-CE VPN label in 
MPLS [RFC4364]. 


The End.DX4 SID MUST be the last segment in an SR Policy, and it is associated with one or more 
L3 IPv4 adjacencies J. 


When N receives a packet destined to S and S is a local End.DX4 SID, N does the following: 


S01. When an SRH is processed { 

$02. If (Segments Left != 0) { 

S03: Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 


S04. } 
S05. Proceed to process the next header in the packet 
S06. 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.DX4 SID, N does the following: 


S01. If (Upper-Layer header type == 4(IPv4) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s03. Forward the exposed IPv4 packet to the L3 adjacency J 
S04. } Else { 
S05: Process as per Section 4.1.1 
S06. } 
Note: 


S01. "4" refers to "IPv4 encapsulation" as defined in the IANA "Assigned Internet 
Protocol Numbers" registry. 


S03. If the End.DX4 SID is bound to an array of L3 adjacencies, then one entry of the 
array is selected based on the hash of the packet's header (see Section 7). 
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4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 


The "Endpoint with decapsulation and specific IPv6 table lookup" behavior ("End.DT6" for short) 
is a variant of the End.T behavior. 


One of the applications of the End.DT6 behavior is the L3VPNV6 use case where a FIB lookup ina 
specific tenant table at the egress PE is required. This is equivalent to the per-VRF VPN label in 
MPLS [RFC4364]. 


Note that an End.DT6 may be defined for the main IPv6 table, in which case an End.DT6 supports 
the equivalent of an IPv6-in-IPv6 decapsulation (without VPN/tenant implication). 


The End.DT6 SID MUST be the last segment in an SR Policy, and a SID instance is associated with 
an IPv6 FIB table T. 


When N receives a packet destined to S and S is a local End.DT6 SID, N does the following: 


S01. When an SRH is processed { 

S02. If (Segments Left != 0) { 

s03. Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 


S04. } 
S05. Proceed to process the next header in the packet 
S06. 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.DT6 SID, N does the following: 


S01. If (Upper-Layer header type == 41(IPv6) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s03. Set the packet's associated FIB table to T 
S04. Submit the packet to the egress IPv6 FIB lookup for 


transmission to the new destination 
S05. } Else { 
S@6. Process as per Section 4.1.1 
S07. } 


4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 


The "Endpoint with decapsulation and specific IPv4 table lookup" behavior ("End.DT4" for short) 
is a variant of the End.T behavior. 


One of the applications of the End.DT4 behavior is the L3VPNV4 use case where a FIB lookup ina 
specific tenant table at the egress PE is required. This is equivalent to the per-VRF VPN label in 
MPLS [RFC4364]. 
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Note that an End.DT4 may be defined for the main IPv4 table, in which case an End.DT4 supports 
the equivalent of an IPv4-in-IPv6 decapsulation (without VPN/tenant implication). 


The End.DT4 SID MUST be the last segment in an SR Policy, and a SID instance is associated with 
an IPv4 FIB table T. 


When N receives a packet destined to S and S is a local End.DT4 SID, N does the following: 


S01. When an SRH is processed { 

S02. If (Segments Left != 0) { 

s03. Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 


S04. } 
S05. Proceed to process the next header in the packet 
S06. 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.DT4 SID, N does the following: 


S01. If (Upper-Layer header type == 4(IPv4) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s03. Set the packet's associated FIB table to T 
S04. Submit the packet to the egress IPv4 FIB lookup for 


transmission to the new destination 
S05. } Else { 
S@6. Process as per Section 4.1.1 
S07. } 


4.8. End.DT46: Decapsulation and Specific IP Table Lookup 


The "Endpoint with decapsulation and specific IP table lookup" behavior ("End.DT46" for short) is 
a variant of the End.DT4 and End.DT6 behavior. 


One of the applications of the End.DT46 behavior is the L3VPN use case where a FIB lookup ina 
specific IP tenant table at the egress PE is required. This is equivalent to the single per-VRF VPN 
label (for IPv4 and IPv6) in MPLS [RFC4364]. 


Note that an End.DT46 may be defined for the main IP table, in which case an End.DT46 supports 
the equivalent of an IP-in-IPv6 decapsulation (without VPN/tenant implication). 


The End.DT46 SID MUST be the last segment in an SR Policy, and a SID instance is associated with 
an IPv4 FIB table T4 and an IPv6 FIB table T6. 
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When N receives a packet destined to S and S is a local End.DT46 SID, N does the following: 


S01. When an SRH is processed { 

S02. If (Segments Left != ð) { 

S037 Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 

S04. 


S05. Proceed to process the next header in the packet 
$06. } 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.DT46 SID, N does the following: 


S01. If (Upper-Layer header type == 4(IPv4) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s03. Set the packet's associated FIB table to T4 
S04. Submit the packet to the egress IPv4 FIB lookup for 


transmission to the new destination 
S05. } Else if (Upper-Layer header type == 41(IPv6) ) { 


S06. Remove the outer IPv6 header with all its extension headers 
S07. Set the packet's associated FIB table to T6 
Ses. Submit the packet to the egress IPv6 FIB lookup for 


transmission to the new destination 
S09. } Else { 
silo: Process as per Section 4.1.1 
SMe T 


4.9. End.DX2: Decapsulation and L2 Cross-Connect 


The "Endpoint with decapsulation and L2 cross-connect" behavior ("End.DX2" for short) is a 
variant of the Endpoint behavior. 


One of the applications of the End.DX2 behavior is the L2VPN [RFC4664] / EVPN Virtual Private 
Wire Service (VPWS) [RFC7432] [RFC8214] use case. 


The End.DX2 SID MUST be the last segment in an SR Policy, and it is associated with one outgoing 
interface I. 
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When N receives a packet destined to S and S is a local End.DX2 SID, N does the following: 


S01. When an SRH is processed { 

S02. If (Segments Left != ð) { 

S037 Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 

S04. 


S05. Proceed to process the next header in the packet 
$06. } 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.DX2 SID, N does the following: 


S01. If (Upper-Layer header type == 143(Ethernet) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s93. Forward the Ethernet frame to the OIF I 
S04. } Else { 
S057 Process as per Section 4.1.1 
S06. 
Note: 


S01. IANA has allocated value "143" for "Ethernet" [[EEE.802.3_2018] in the "Assigned 
Internet Protocol Numbers" registry (see Section 10.1). 


S03. An End.DX2 behavior could be customized to expect a specific IEEE header (e.g., 
VLAN tag) and rewrite the egress IEEE header before forwarding on the outgoing 
interface. 


Note that an End.DX2 SID may also be associated with a bundle of outgoing interfaces. 


4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 


The "Endpoint with decapsulation and VLAN L2 table lookup" behavior ("End.DX2V" for short) is 
a variant of the End.DX2 behavior. 


One of the applications of the End.DX2V behavior is the EVPN Flexible Cross-connect use case. 
The End.DX2V behavior is used to perform a lookup of the Ethernet frame VLANs in a particular 
L2 table. Any SID instance of this behavior is associated with an L2 table T. 


When N receives a packet whose IPv6 DA is S and S is a local End.DX2 SID, the processing is 
identical to the End.DX2 behavior except for the Upper-Layer header processing, which is 
modified as follows: 


S03. Look up the exposed VLANs in L2 table T, and forward 
via the matched table entry. 
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Note: 


S03. An End.DX2V behavior could be customized to expect a specific VLAN format 
and rewrite the egress VLAN header before forwarding on the outgoing interface. 


4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 


The "Endpoint with decapsulation and unicast MAC L2 table lookup" behavior ("End.DT2U" for 
short) is a variant of the End behavior. 


One of the applications of the End.DT2U behavior is the EVPN Bridging Unicast [RFC7432]. Any 
SID instance of the End.DT2U behavior is associated with an L2 table T. 


When N receives a packet whose IPv6 DA is S and S is a local End.DT2U SID, the processing is 
identical to the End.DX2 behavior except for the Upper-Layer header processing, which is as 
follows: 


S01. If (Upper-Layer header type == 143(Ethernet) ) { 


s02. Remove the outer IPv6 header with all its extension headers 
s03. Learn the exposed MAC Source Address in L2 table T 
S04. Look up the exposed MAC Destination Address in L2 table T 
S05. If (matched entry in T) { 
S06. Forward via the matched table T entry 
S07. } Else { 
Ses. Forward via all L2 OIFs in table T 
Seo. } 
S10. } Else { 
$11. Process as per Section 4.1.1 
SIZ 
Note: 


S01. IANA has allocated value "143" for "Ethernet" in the "Assigned Internet Protocol 
Numbers" registry (see Section 10.1). 


S03. In EVPN [RFC7432], the learning of the exposed MAC Source Address is done via 
the control plane. In L2VPN Virtual Private LAN Service (VPLS) [RFC4761] 
[RFC4762], reachability is obtained by standard learning bridge functions in the 
data plane. 


4.12. End.DT2M: Decapsulation and L2 Table Flooding 


The "Endpoint with decapsulation and L2 table flooding" behavior ("End.DT2M" for short) is a 
variant of the End.DT2U behavior. 


Two of the applications of the End.DT2M behavior are the EVPN Bridging of Broadcast, Unknown 
Unicast, and Multicast (BUM) traffic with Ethernet Segment Identifier (ESD filtering [RFC7432] 
and the EVPN Ethernet-Tree (E-Tree) [RFC8317] use cases. 
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Any SID instance of this behavior is associated with an L2 table T. The behavior also takes an 
argument: "Arg.FE2". This argument provides a local mapping to ESI for split-horizon filtering of 
the received traffic to exclude a specific OIF (or set of OIFs) from L2 table T flooding. The 
allocation of the argument values is local to the SR Segment Endpoint Node instantiating this 
behavior, and the signaling of the argument to other nodes for the EVPN functionality occurs via 
the control plane. 


When N receives a packet whose IPv6 DA is S and S is a local End.DT2M SID, the processing is 
identical to the End.DX2 behavior except for the Upper-Layer header processing, which is as 
follows: 


S01. If (Upper-Layer header type == 143(Ethernet) ) { 


$02: Remove the outer IPv6 header with all its extension headers 
s03. Learn the exposed MAC Source Address in L2 table T 
S04. Forward via all L2 OIFs excluding those associated with the 


identifier Arg.FE2 
S05. } Else { 


S@6. Process as per Section 4.1.1 
S07. 


Note: 


S01. IANA has allocated value "143" for "Ethernet" in the "Assigned Internet Protocol 
Numbers" registry (see Section 10.1). 


S03. In EVPN [RFC7432], the learning of the exposed MAC Source Address is done via 
the control plane. In L2VPN VPLS [RFC4761] [RFC4762], reachability is obtained by 
standard learning bridge functions in the data plane. 


4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy with Encapsulation 


This is a variation of the End behavior. 


One ofits applications is to express scalable traffic-engineering policies across multiple domains. 
It is one of the SRv6 instantiations of a Binding SID [RFC8402]. 


Any SID instance of this behavior is associated with an SR Policy B and a source address A. 
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When N receives a packet whose IPv6 DA is S and S is a local End.B6.Encaps SID, N does the 
following: 


S01. When an SRH is processed { 

$02. If (Segments Left == 0) { 

$03. Stop processing the SRH, and proceed to process the next 
header in the packet, whose type is identified by 
the Next Header field in the routing header. 


S04. } 

S@5. If (IPv6 Hop Limit <= 1) { 

S06. Send an ICMP Time Exceeded message to the Source Address 
with Code @ (Hop limit exceeded in transit), 
interrupt packet processing, and discard the packet. 

S07. } 


Ses. max_LE = (Hdr Ext Len / 2) - 1 
Seg. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 
S10. Send an ICMP Parameter Problem to the Source Address 
with Code @ (Erroneous header field encountered) 
and Pointer set to the Segments Left field, 
interrupt packet processing, and discard the packet. 
Sie 
S12. Decrement IPv6 Hop Limit by 1 
SiB: Decrement Segments Left by 1 
$14. Update IPv6é DA with Segment List[Segments Left] 
S15. Push a new IPv6 header with its own SRH containing B 
S16. Set the outer IPv6 SA to A 
S17. Set the outer IPv6 DA to the first SID of B 
S18. Set the outer Payload Length, Traffic Class, Flow Label, 
Hop Limit, and Next Header fields 
S19. Submit the packet to the egress IPv6 FIB lookup for 
transmission to the new destination 
S20. } 


Note: 


S15. The SRH MAY be omitted when the SRv6 Policy B only contains one SID and 
there is no need to use any flag, tag, or TLV. 


S18. The Payload Length, Traffic Class, Hop Limit, and Next Header fields are set as 
per [RFC2473]. The Flow Label is computed as per [RFC6437]. 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.B6.Encaps SID, process the packet as per Section 4.1.1. 


4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 


This is an optimization of the End.B6.Encaps behavior. 


End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding the first SID in the SRH of 
the new IPv6 header. Thus, the first segment is only placed in the IPv6 Destination Address of the 
new IPv6 header, and the packet is forwarded according to it. 


The SRH Last Entry field is set as defined in Section 4.1.1 of [RFC8754]. 
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The SRH MAY be omitted when the SRv6 Policy only contains one SID and there is no need to use 
any flag, tag, or TLV. 


4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 


The "Endpoint bound to an SR-MPLS Policy" behavior ("End.BM" for short) is a variant of the End 
behavior. 


The End.BM behavior is required to express scalable traffic-engineering policies across multiple 
domains where some domains support the MPLS instantiation of Segment Routing. This is an 
SRV6 instantiation of an SR-MPLS Binding SID [RFC8402]. 


Any SID instance of this behavior is associated with an SR-MPLS Policy B. 


When N receives a packet whose IPv6 DA is S and S is a local End.BM SID, N does the following: 


S01. When an SRH is processed { 

$02. If (Segments Left == 9) { 

$03. Stop processing the SRH, and proceed to process the next 
header in the packet, whose type is identified by 
the Next Header field in the routing header. 


S04. } 

S@5. If (IPv6 Hop Limit <= 1) { 

S06. Send an ICMP Time Exceeded message to the Source Address 
with Code @ (Hop limit exceeded in transit), 
interrupt packet processing, and discard the packet. 

S07. } 


S08. max LE = (Hdr Ext Len / 2) - 1 
Seg. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 
S10. Send an ICMP Parameter Problem to the Source Address 

with Code @ (Erroneous header field encountered) 

and Pointer set to the Segments Left field, 

interrupt packet processing, and discard the packet. 


Sites 

$12. Decrement IPv6 Hop Limit by 1 

Si? Decrement Segments Left by 1 

$14. Update IPv6 DA with Segment List[Segments Left] 

S15. Push the MPLS label stack for B 

S16. Submit the packet to the MPLS engine for transmission 
Sie T 


When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as 
an End.BM SID, process the packet as per Section 4.1.1. 


4.16. Flavors 


The Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (USP) of the SRH, and 
Ultimate Segment Decapsulation (USD) flavors are variants of the End, End.X, and End.T 
behaviors. The End, End.X, and End.T behaviors can support these flavors either individually or 
in combinations. 
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4.16.1. PSP: Penultimate Segment Pop of the SRH 


4.16.1.1. Guidelines 


SR Segment Endpoint Nodes advertise the SIDs instantiated on them via control-plane protocols 
as described in Section 8. Different behavior IDs are allocated for flavored and unflavored SIDs 
(see Table 6). 


An SR Segment Endpoint Node that offers both PSP- and non-PSP-flavored behavior advertises 
them as two different SIDs. 


The SR Segment Endpoint Node only advertises the PSP flavor if the operator enables this 
capability at the node. 


The PSP operation is deterministically controlled by the SR source node. 


A PSP-flavored SID is used by the SR source node when it needs to instruct the penultimate SR 
Segment Endpoint Node listed in the SRH to remove the SRH from the IPv6 header. 


4.16.1.2. Definition 


SR Segment Endpoint Nodes receive the IPv6 packet with the Destination Address field of the 
IPv6 header equal to its SID address. 


A penultimate SR Segment Endpoint Node is one that, as part of the SID processing, copies the 
last SID from the SRH into the IPv6 Destination Address and decrements the Segments Left value 
from one to zero. 


The PSP operation only takes place at a penultimate SR Segment Endpoint Node and does not 
happen at any transit node. When a SID of PSP flavor is processed at a non-penultimate SR 
Segment Endpoint Node, the PSP behavior is not performed as described in the pseudocode 
below since Segments Left would not be zero. 


The SRH processing of the End, End.X, and End.T behaviors are modified: after the instruction 
"$14. Update IPv6 DA with Segment List[Segments Left]" is executed, the following instructions 
must be executed as well: 


SiAeae If (Segments Left == 0) { 
SIAT 2: Update the Next Header field in the preceding header to 
the Next Header value from the SRH 
S143: Decrease the IPv6 header Payload Length by 
8*(Hdr Ext Len+1) 
$14.4. Remove the SRH from the IPv6 extension header chain 
$14.5. } 


The usage of PSP does not increase the MTU of the IPv6 packet and hence does not have any 
impact on the Path MTU (PMTU) discovery mechanism. 
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As a reminder, Section 5 of [RFC8754] defines the SR Deployment Model within the SR Domain 
[RFC8402]. Within this framework, the Authentication Header (AH) is not used to secure the SRH 
as described in Section 7.5 of [RFC8754]. Hence, the discussion of applicability of PSP along with 
AH usage is beyond the scope of this document. 


In the context of this specification, the End, End.X, and End.T behaviors with PSP do not 
contravene Section 4 of [RFC8200] because the destination address of the incoming packet is the 
address of the node executing the behavior. 


4.16.1.3. Use Case 
One use case for the PSP functionality is streamlining the operation of an egress border router. 


+---------------------------------------------------- + 

| | 
+-+-+ +--+ +--+ +--+ +-+-+ 
[aU titi ERZE R >+R4+-------- >+ePE | 
| R1| +--+ +--+ +--+ IRSA] 
+-+-+ +----- + +----- + +----- + +----- + +-+-+ 

l |IPve | |IPv6 | |IPv6 | |IPv6 | l 

l | DA=R3 | | DA=R3 | | DA=R5 | | DA=R5 | l 

| +----- + +----- + +----- + +----- + | 

l | SRH | | SRH | | 2a | [ete 

l |SL=1 | |SL=1 | oo + +----- + | 

| I R5 | | R5 | | 

| +----- + +----- + | 

| | IP | | IP | | 

| +----- + +----- + | 

| | 

+---------------------------------------------------- + 


Figure 1: PSP Use Case Topology 


In the above illustration, for a packet sent from the ingress provider edge (iPE) to the egress 
provider edge (ePE), node R3 is an intermediate traffic-engineering waypoint and is the 
penultimate segment endpoint router; this node copies the last segment from the SRH into the 
IPv6 Destination Address and decrements Segments Left to 0. The Software-Defined Networking 
(SDN) controller knows that no other node after R3 needs to inspect the SRH, and it instructs R3 
to remove the exhausted SRH from the packet by using a PSP-flavored SID. 


The benefits for the egress PE are straightforward: 


e As part of the decapsulation process, the egress PE is required to parse and remove fewer 
bytes from the packet. 

e If a lookup on an upper-layer IP header is required (e.g., per-VRF VPN), the header is more 
likely to be within the memory accessible to the lookup engine in the forwarding ASIC 
(Application-Specific Integrated Circuit). 
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4.16.2. USP: Ultimate Segment Pop of the SRH 


The SRH processing of the End, End.X, and End.T behaviors are modified; the instructions S02- 
S04 are substituted by the following ones: 


502. If (Segments Left == 0) { 

$03.1. Update the Next Header field in the preceding header to 
the Next Header value of the SRH 

$03.2. Decrease the IPv6 header Payload Length by 
8*(Hdr Ext Len+1) 

$03.3. Remove the SRH from the IPv6 extension header chain 

$03.4. Proceed to process the next header in the packet 

S04. } 


One of the applications of the USP flavor is when a packet with an SRH is destined to an 
application on hosts with smartNICs ("Smart Network Interface Cards") implementing SRv6. The 
USP flavor is used to remove the consumed SRH from the extension header chain before sending 
the packet to the host. 


4.16.3. USD: Ultimate Segment Decapsulation 


The Upper-Layer header processing of the End, End.X, and End.T behaviors are modified as 
follows: 


End: 


S01. If (Upper-Layer header type == 41(IPv6) ) { 

S02. Remove the outer IPv6 header with all its extension headers 

s03. Submit the packet to the egress IPv6 FIB lookup for 
transmission to the new destination 

S04. } Else if (Upper-Layer header type == 4(IPv4) ) { 


S05. Remove the outer IPv6 header with all its extension headers 

S06. Submit the packet to the egress IPv4 FIB lookup for 
transmission to the new destination 

S07. Else { 

Se8. Process as per Section 4.1.1 

Seg. 
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End tT: 


S01. If (Upper-Layer header type == 41(IPv6) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s03. Set the packet's associated FIB table to T 
S04. Submit the packet to the egress IPv6 FIB lookup for 


transmission to the new destination 
S05. } Else if (Upper-Layer header type == 4(IPv4) ) { 


S06. Remove the outer IPv6 header with all its extension headers 
S07. Set the packet's associated FIB table to T 
Ses. Submit the packet to the egress IPv4 FIB lookup for 
transmission to the new destination 
S09. Else { 
$10. Process as per Section 4.1.1 
Sii. 4 
End.x: 


S01. If (Upper-Layer header type == 41(IPv6) || 
Upper-Layer header type == 4(IPv4) ) { 


S02. Remove the outer IPv6 header with all its extension headers 
s03. Forward the exposed IP packet to the L3 adjacency J 

S04. } Else { 

S05- Process as per Section 4.1.1 

S06. 


One of the applications of the USD flavor is the case of a Topology Independent Loop-Free 
Alternate (TI-LFA) in P routers with encapsulation. The USD flavor allows the last SR Segment 
Endpoint Node in the repair path list to decapsulate the IPv6 header added at the TI-LFA Point of 
Local Repair and forward the inner packet. 


5. SR Policy Headend Behaviors 
This section describes a set of SRv6 Policy Headend [RFC8402] behaviors. 


H.Encaps SR Headend with Encapsulation in an SR Policy 
H.Encaps.Red H.Encaps with Reduced Encapsulation 
H.Encaps.L2 H.Encaps Applied to Received L2 Frames 


H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 
Table 2: SR Policy Headend Behaviors 


This list is not exhaustive, and future documents may define additional behaviors. 
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5.1. H.Encaps: SR Headend with Encapsulation in an SR Policy 

Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; SL=1). B2 is neither a local 
address nor SID of N. 

Node N is configured with an IPv6 address T (e.g., assigned to its loopback). 


N steers the transit packets P1 and P2 into an SRv6 Policy with a Source Address T and a segment 
list <S1, $2, $3>, 


The H.Encaps encapsulation behavior is defined as follows: 


Soi. Push an IPv6 header with its own SRH 

S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID 
in the segment list 

s03. Set outer Payload Length, Traffic Class, Hop Limit, and 
Flow Label fields 

S04. Set the outer Next Header value 

S505: Decrement inner IPv6 Hop Limit or IPv4 TTL 

S06. Submit the packet to the IPv6 module for transmission to S1 


Note: 
S03: As described in [RFC2473] and [RFC6437]. 


After the H.Encaps behavior, P1' and P2' respectively look like: 


e (T, S1) (S3, S2, S1; SL=2) (A, B2) 
e (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 


The received packet is encapsulated unmodified (with the exception of the IPv4 TTL or IPv6 Hop 
Limit that is decremented as described in [RFC2473]). 


The H.Encaps behavior is valid for any kind of L3 traffic. This behavior is commonly used for 
L3VPN with IPv4 and IPv6 deployments. It may be also used for TI-LFA [SR-TI-LFA] at the Point of 
Local Repair. 


The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there 
is no need to use any flag, tag, or TLV. 


5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 


The H.Encaps.Red behavior is an optimization of the H.Encaps behavior. 


H.Encaps.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed 
IPv6 header. The first SID is only placed in the Destination Address field of the pushed IPv6 
header. 
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After the H.Encaps.Red behavior, P1' and P2' respectively look like: 


e (T, S1) (S3, S2; SL=2) (A, B2) 
° (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 


The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there 
is no need to use any flag, tag, or TLV. 


5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 


The H.Encaps.L2 behavior encapsulates a received Ethernet [IEEE.802.3_2018] frame and its 
attached VLAN header, if present, in an IPv6 packet with an SRH. The Ethernet frame becomes 
the payload of the new IPv6 packet. 


The Next Header field of the SRH MUST be set to 143. 


The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there 
is no need to use any flag, tag, or TLV. 


The encapsulating node MUST remove the preamble (if any) and frame check sequence (FCS) 
from the Ethernet frame upon encapsulation, and the decapsulating node MUST regenerate, as 
required, the preamble and FCS before forwarding the Ethernet frame. 


5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 Frames 


The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 behavior. 


H.Encaps.L2.Red reduces the length of the SRH by excluding the first SID in the SRH of the 
pushed IPv6 header. The first SID is only placed in the Destination Address field of the pushed 
IPv6 header. 


The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there 
is no need to use any flag, tag, or TLV. 


6. Counters 


A node supporting this document SHOULD implement a pair of traffic counters (one for packets 
and one for bytes) per local SID entry, for traffic that matched that SID and was processed 
successfully (i.e., packets that generate ICMP Error Messages or are dropped are not counted). 
The retrieval of these counters from MIB, NETCONF/YANG, or any other data structure is outside 
the scope of this document. 


7. Flow-Based Hash Computation 


When a flow-based selection within a set needs to be performed, the IPv6 Source Address, the 
IPv6 Destination Address, and the IPv6 Flow Label of the outer IPv6 header MUST be included in 
the flow-based hash. 
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This may occur in any of the following scenarios: 
e A FIB lookup is performed and multiple ECMP paths exist to the updated destination address. 
e End.X, End.DX4, or End.DX6 is bound to an array of adjacencies. 
e The packet is steered in an SR Policy whose selected path has multiple SID lists. 


Additionally, any transit router in an SRv6 domain includes the outer flow label in its ECMP flow- 
based hash [RFC6437]. 


8. Control Plane 


In an SDN environment, one expects the controller to explicitly provision the SIDs and/or 
discover them as part of a service discovery function. Applications residing on top of the 

controller could then discover the required SIDs and combine them to form a distributed 
network program. 


The concept of "SRv6 Network Programming" refers to the capability of an application to encode 
any complex program as a set of individual functions distributed through the network. Some 
functions relate to underlay SLA, others to overlay/tenant, and others to complex applications 
residing in VMs and containers. 


While not necessary for an SDN control plane, the remainder of this section provides a high-level 
illustrative overview of how control-plane protocols may be involved with SRv6. Their 
specification is outside the scope of this document. 


8.1. IGP 


The End, End.T, and End.X SIDs express topological behaviors and hence are expected to be 
signaled in the IGP together with the flavors PSP, USP, and USD. The IGP should also advertise the 
Maximum SID Depth (MSD) capability of the node for each type of SRV6 operation -- in particular, 
the SR source (e.g., H.Encaps), intermediate endpoint (e.g., End and End.X), and final endpoint 
(e.g., End.DX4 and End.DT6) behaviors. These capabilities are factored in by an SR source node 
(or a controller) during the SR Policy computation. 


The presence of SIDs in the IGP does not imply any routing semantics to the addresses 
represented by these SIDs. The routing reachability to an IPv6 address is solely governed by the 
non-SID-related IGP prefix reachability information that includes locators. Routing is neither 
governed nor influenced in any way by a SID advertisement in the IGP. 


These SIDs provide important topological behaviors for the IGP to build Fast Reroute (FRR) 
solutions based on TI-LFA [SR-TI-LFA] and for TE processes relying on an IGP topology database 
to build SR Policies. 
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8.2. BGP-LS 


BGP-LS provides the functionality for topology discovery that includes the SRv6 capabilities of 
the nodes, their locators, and locally instantiated SIDs. This enables controllers or applications to 
build an inter-domain topology that can be used for computation of SR Policies using the SRv6 
SIDs. 


8.3. BGP IP/VPN/EVPN 


The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, End.DT2U, and 
End.DT2M SIDs can be signaled in BGP. 


In some scenarios, an egress PE advertising a VPN route might wish to abstract the specific 
behavior bound to the SID from the ingress PE and other routers in the network. In such case, 
the SID may be advertised using the Opaque SRv6 Endpoint Behavior codepoint defined in Table 
6. The details of such control-plane signaling mechanisms are out of the scope of this document. 


8.4. Summary 


The following table summarizes which SID behaviors may be signaled in which control-plane 
protocol. 


IGP BGP-LS BGP IP/VPN/EVPN 


End (PSP, USP, USD) X X 

End.X (PSP, USP, USD) X X 

End.T (PSP, USP, USD) X X 

End.DX6 X X X 
End.DX4 X X X 
End.DT6 X X X 
End.DT4 X X X 
End.DT46 X X X 
End.DX2 X X 
End.DX2V X X 
End.DT2U X X 
End.DT2M X X 
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IGP BGP-LS BGP IP/VPN/EVPN 


End.B6.Encaps X 
End.B6.Encaps.Red X 
End.B6.BM X 


Table 3: SRv6 Locally Instantiated SIDs Signaling 


The following table summarizes which SR Policy Headend capabilities may be signaled in which 
control-plane protocol. 


IGP BGP-LS BGP IP/VPN/EVPN 


H.Encaps X X 
H.Encaps.Red X X 
H.Encaps.L2 X 
H.Encaps.L2.Red X 


Table 4: SRv6 Policy Headend Behaviors Signaling 


The previous table describes generic capabilities. It does not describe specific instantiated SR 
Policies. 


For example, a BGP-LS advertisement of H.Encaps behavior would describe the capability of 
node N to perform H.Encaps behavior. Specifically, it would describe how many SIDs could be 
pushed by N without significant performance degradation. 


As a reminder, an SR Policy is always assigned a Binding SID [RFC8402]. Binding SIDs are also 
advertised in BGP-LS as shown in Table 3. Hence, Table 4 only focuses on the generic capabilities 
related to H.Encaps. 


9. Security Considerations 


The security considerations for Segment Routing are discussed in [RFC8402]. Section 5 of 
[RFC8754] describes the SR Deployment Model and the requirements for securing the SR Domain. 
The security considerations of [RFC8754] also cover topics such as attack vectors and their 
mitigation mechanisms that also apply the behaviors introduced in this document. Together, they 
describe the required security mechanisms that allow establishment of an SR domain of trust. 
Having such a well-defined trust boundary is necessary in order to operate SRv6-based services 
for internal traffic while preventing any external traffic from accessing or exploiting the SRv6- 
based services. Care and rigor in IPv6 address allocation for use for SRv6 SID allocations and 
network infrastructure addresses, as distinct from IPv6 addresses allocated for end users and 
systems (as illustrated in Section 5.1 of [RFC8754]), can provide the clear distinction between 
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internal and external address space that is required to maintain the integrity and security of the 
SRv6 Domain. Additionally, [RFC8754] defines a Hashed Message Authentication Code (HMAC) 
TLV permitting SR Segment Endpoint Nodes in the SR domain to verify that the SRH applied toa 
packet was selected by an authorized party and to ensure that the segment list is not modified 
after generation, regardless of the number of segments in the segment list. When enabled by 
local configuration, HMAC processing occurs at the beginning of SRH processing as defined in 
Section 2.1.2.1 of [RFC8754]. 


This document introduces SRv6 Endpoint and SR Policy Headend behaviors for implementation 
on SRv6-capable nodes in the network. The definition of the SR Policy Headend should be 
consistent with the specific behavior used and any local configuration (as specified in Section 
4.1.1). As such, this document does not introduce any new security considerations. 


The SID behaviors specified in this document have the same HMAC TLV handling and mutability 
properties with regard to the Flags, Tag, and Segment List field as the SID behavior specified in 
[RFC8754]. 


10. IANA Considerations 


10.1. Ethernet Next Header Type 


IANA has allocated "Ethernet" (value 143) in the "Assigned Internet Protocol Numbers" registry 
(see <https://www.iana.org/assignments/protocol-numbers/>). Value 143 in the Next Header field 
of an IPv6 header or any extension header indicates that the payload is an Ethernet frame 
[IEEE.802.3_2018]. 


10.2. SRv6 Endpoint Behaviors Registry 


IANA has created a new top-level registry called "Segment Routing" (see <https://www.iana.org/ 
assignments/segment-routing/>). This registry serves as a top-level registry for all Segment 
Routing subregistries. 


Additionally, IANA has created a new subregistry called "SRv6 Endpoint Behaviors" under the 
top-level "Segment Routing" registry. This subregistry maintains 16-bit identifiers for the SRv6 
Endpoint behaviors. This registry is established to provide consistency for control-plane 
protocols that need to refer to these behaviors. These values are not encoded in the function bits 
within a SID. 


10.2.1. Registration Procedures 


The range of the registry is 0-65535 (0x0000-OxFFFF). The table below contains the allocation 
ranges and registration policies [RFC8126] for each: 


Range Range (Hex) Registration Procedures Note 


0 0x0000 Reserved Not to be allocated 
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Range 
1-32767 
32768-34815 
34816-65534 


65535 
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Range (Hex) Registration Procedures 


0x0001-0x7FFF First Come First Served 


0x8000-0x87FF Private Use 
0x8800-OxFFFE Reserved 
OxFFFF Reserved 


Table 5: Registration Procedures 


10.2.2. Initial Registrations 


The initial registrations for the subregistry are as follows: 


Value 


0 


1 
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Hex Endpoint Behavior 
0x0000 Reserved 
0x0001 End 
0x0002 End with PSP 
0x0003 End with USP 
0x0004 End with PSP & USP 
0x0005 End.X 
0x0006 End.X with PSP 
0x0007 End.X with USP 
0x0008 End.X with PSP & USP 
0x0009 End.T 
0x000A End.T with PSP 
0x000B End.T with USP 
0x000C End.T with PSP & USP 
0x000D Unassigned 
0x000E End.B6.Encaps 
0x000F End.BM 
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Note 


Opaque 


Reference 


RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 
RFC 8986 


RFC 8986 


RFC 8986 


RFC 8986 


Page 33 


RFC 8986 


Value 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 


39 
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Hex 


0x0010 


0x0011 


0x0012 


0x0013 


0x0014 


0x0015 


0x0016 


0x0017 


0x0018 


0x0019 


0x001A 


0x001B 


0x001C 


0x001D 


0x001E 


0x001F 


0x0020 


0x0021 


0x0022 


0x0023 


0x0024 


0x0025 


0x0026 


0x0027 
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Endpoint Behavior 
End.DX6 
End.DX4 
End.DT6 
End.DT4 
End.DT46 
End.DX2 

End.DX2V 
End.DT2U 
End.DT2M 
Reserved 
Unassigned 
End.B6.Encaps.Red 
End with USD 
End with PSP & USD 
End with USP & USD 
End with PSP, USP & USD 
End.X with USD 
End.X with PSP & USD 
End.X with USP & USD 
End.X with PSP, USP & USD 
End.T with USD 
End.T with PSP & USD 
End.T with USP & USD 


End.T with PSP, USP & USD 
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Value Hex Endpoint Behavior Reference 
40-32766 0x0028-0x7FFE Unassigned 
32767 Ox7FFF The SID defined in RFC 8754 RFC 8986, RFC 8754 
32768-34815 0x8000-0x87FF Reserved for Private Use RFC 8986 
34816-65534 0x8800-OxFFFE Reserved RFC 8986 
65535 OXFFFF Opaque RFC 8986 


Table 6: Initial Registrations 
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